Épisode 1 - Expériences design system podcast

Écouter l'épisode sur Anchor
Le lien du flux RSS : https://anchor.fm/s/13f47988/podcast/rss

Les invités

Hélène Legendre, UX writer chez Openclassrooms
Hubert Sablonnière, développeur web chez Clever Cloud

La transcription

- Introduction : Bonjour et bienvenue sur le podcast Expériences design system. Il s’agit d’un podcast qui parle des design systems sous toutes leurs facettes. Nous aurons à chaque épisode deux invités aux expériences différentes.

- Cécile : Merci d'être là avec nous. Peut-être qu’on peut commencer par faire un petit tour de table. Hélène, à toi l'honneur.

- Hélène : Yes ! Donc du coup, je suis Hélène. Je travaille actuellement en tant qu’UX writer chez Openclassrooms, qui est une entreprise qui propose des formations diplômantes 100 % en ligne. Et aussi, et c'est ce pourquoi on connait tous Openclassrooms, des cours accessibles et gratuits. Donc voilà, je fais partie d'une équipe de 4 UX writers, ce qui est très chouette actuellement. On est deux anglophones, deux francophones dont moi. Ça fait à peu près 2 ans que je fais de l'UX writing. Et avant, j'étais chef de projet dans une agence qui crée des sites et des plateformes digitales.

- Hubert : Alors moi je suis Hubert, je travaille chez Clever Cloud. Chez Clever Cloud, je m'occupe de tout ce qui est front-end et on a commencé il y a peu, il y a presque trois ans, une bibliothèque de composants qui, un jour, sera peut être un vrai design system. Et donc, moi, je vais être développeur sur tout ça, mais on en discutera après. Je fus amené, vu la taille de l'équipe qu'on a, à faire un peu de tout et entre autres aussi les maquettes, le design, les traductions et tout ce qui n'est pas officiellement du dev. Je tape aussi du code.

- Cécile : Donc, du coup, aujourd'hui, on va parler d’UX writing et plus particulièrement de sa place au sein d'un d'un design system. Hélène, toi, c'est ton métier, peux-tu nous expliquer un peu ce que sait ?

- Hélène : L’UX writing Dans un premier temps, c'est mon point de vue mais je pense qu'il est partagé par un certain nombre de personnes, c'est l’importance accordée aux mots. L'importance qu'ils méritent, c'est les contenus qui concourent, qui participent à créer une meilleure expérience pour les utilisateurs. Et c'est en prendre soin et encore une fois, leur accorder l'importance qu'ils méritent de manière un peu plus pragmatique. C'est le contenu qu'on va trouver dans les expériences, dans les interfaces. Typiquement, des labels de boutons, des messages d'erreurs, des titres, des descriptions et d'autres encore. Plus concrètement, l'UX writing, c'est rédiger de manière claire, concise. C'est-à-dire être aussi bref que possible et toujours garder en tête pour qui on écrit, pourquoi on écrit et à quel moment de l'expérience ça va s'afficher. Donc tout ça, c'est très, très relatif aux mots, mais c'est aussi bien penser à l'architecture de l'information et s'assurer que c'est cohérent. Et encore une fois, que ça adresse bien le besoin de l'utilisateur au moment opportun. Et en termes de process, nous, les UX writers ce qu'on essaye de faire, c'est de participer au maximum à toutes les étapes du design. Donc, on travaille vraiment main dans la main avec les product designers au sein des équipes. Donc moi, je suis vraiment dans l'équipe design et on travaille sur les mêmes projets. Il y a même des projets qui peuvent être content-first. C'est à dire qu'avant même de penser au design, on va penser au contenu déjà en première étape. Voilà. Globalement, c'est un peu différent de la conception rédaction qu'on connait un petit peu plus parce que plus présente dans les équipes marketing. On pense souvent au couple concepteur-rédacteur et directeur artistique. Le pendant sur les produits digitaux, c'est le couple Product designer et UX writer/content designer qui est un terme qui émerge petit à petit.

- Cécile : Et du coup. Donc toi, c'est ton métier. Mais toi Hubert, toi qui es tout seul. Tu dois gérer tout ça. Et toi, c'est quoi, ta vision du mot ?

- Hubert : Alors déjà, je vais apporter une petite astérisque. J'ai commencé chez Clever il y a un peu plus de 4 ans et c'est vrai que même si j'étais aidé par certains collègues sur le front-end, j'ai assumé un peu tout seul pas mal de casquettes depuis un an et demi en alternant. Et depuis lundi, j'ai un nouveau collègue. Donc ça y est, je ne suis plus vraiment tout seul. Et donc, il va y avoir un petit challenge de comment on s'organise sur tous ces sujets là. Mais donc, pour répondre à ta question, forcément, quand on est une équipe où on n'a pas toutes les personnes spécialisées dans les compétences qu'a pu citer Hélène, on essaye de faire nous mêmes et de faire un peu au mieux. Alors forcément, ça n'aura pas le même niveau de qualité que quand c'est quelqu'un qui fait ça, qui a été formé pour ça. On se documente, on fait un peu de veille et on va avoir énormément de problématiques qu'on ne sait pas gérer parce qu'on n'a pas d'expérience sur ces sujets là ou très peu. Et on tâtonne. On fait au mieux et je pense qu'on aura l'occasion d'en reparler, mais du coup, sur les termes. Moi, le terme UX writing, je ne le connaissais pas trop. Je ne mettais pas forcément de mots dessus, alors je disais vite fait le wording.

- Hubert : En plus, ça veut pas dire grand chose. Je serais curieux de savoir un anglophone. Quand tu lui dis le wording, est-ce que ça lui parle ? Je sais pas trop d'où j'ai pris ce terme,

- Hélène : Mais je l'ai trouvé sur des contenus écrits par des anglophones. Mais les UX writers anglophones chez Openclassrooms nous disent que ce n'est vraiment pas le terme adapté. On parle plutôt de copie, par exemple.

- Hubert : Oui, oui et et donc, c'est vrai que nous, dans le process de création de nos interfaces, de nos composants, etc. On va avoir tôt ou tard dans le process. Ça va énormément dépendre de ce sur quoi on bosse. Ok, mais on écrit quoi ? Et donc, moi, j'ai mis ce terme de wording. J'ai aussi mis un terme d'internationalisation et de localisation dès qu'il s'agit de faire la version française et anglaise, en l'occurrence chez nous. Et en fait, au fur et à mesure, je découvre des termes, notamment via des discussions que j'ai vues avec vous deux, sur des problématiques que j'ai et sur lequel je n'avais pas forcément les bons termes.

- Hélène : Mais si c'est vrai que c'est souvent la situation que tu décris Hubert/ Je pense qu'elle est partagée par un très grand nombre de personnes et moi, je sais que ce qui a déclenché aussi l'arrivée des UX writer et Openclassrooms, l'une des raisons ? Pas l'unique, mais l'une des raisons, c'est qu’en fin de projet. Il y avait toujours cette espèce de bottleneck, de goulot d'étranglement. Ah, mais en fait, les mots qu'on va mettre dans l'expérience qui s’en occupe ? Est-ce que c'est validé ? Est-ce que c'est traduit ? Il y avait un peu ces questions qui se posaient en fin de fin de projet et qui pouvaient parfois aussi occasionner du retard sur la livraison de certaines fonctionnalités. Donc, c'est l'une des raisons. Pas que. Encore une fois, il y avait des ambitions de qualité aussi et de spécialisation. Mais en tout cas, il y avait aussi cette problématique-là qui a fait qu’aujourd'hui, on y est, on est 4 et on a été 2 au début. Mais en tout cas, je pense que ce sont des questions qu'on se pose aussi beaucoup, nous. La cohérence des termes dans l'expérience. Enfin, on partage les mêmes problématiques, même si moi, du coup, je peux vraiment me concentrer dessus parce que c'est mon métier.

- Cécile : Et tu disais Hubert que tu avais des problématiques est-ce que tu aurais un exemple ? Un exemple concret.

- Hubert : Ce que disait Hélène, typiquement, on l’a rencontré encore récemment. On a mis en ligne un composant pour que les utilisateurs et utilisatrices puissent activer un truc qui s'appelle Grafana. Ça fait des dashboard un peu sympa, ça indique si mes serveurs vont bien ou pas. Et donc, c'est typiquement un composant où ce n'est pas juste un enabled disabled. Et puis le lien pour aller vers le fameux grafana qui a une URL à part. Et donc j'ai un collègue et parce que ce n'est pas moi qui me suis occupé du composant, j'ai supervisé un collègue, je l'ai aidé et donc il a écrit pas mal de “wording”. Il a mis un peu de contexte et un peu entre guillemets, de documentation dans le composant autour du enabled avec des captures d'écran. Et en fait, comme je lui avais délégué le truc, je ne l'ai pas suivi dès le début ce qui s'est passé, il a fait au mieux comme moi je l'aurais fait et on s'est rendu compte que sur la fin, qui avait peut être des problèmes d’inconscitance entre eux. Ah, mais à tel endroit, on appelle ça une application. À tel endroit, on appelle ça un service, mais peut être que c'est en add-on.

- Hubert : Donc, on a eu des “est-ce qu'on appelle vraiment les choses de la même manière partout''. Et en fait, ça comme on n'a jamais mis en place de ubiquitous langage qui est un terme que j'ai appris très récemment, qu'on a pas de dictionnaire, de glossaire, d'index. On a encore des problèmes de consistance dans le nommage. Ça, c'est un truc, un exemple récent que j'ai eu et les autres exemples récents, ça va être même sur le nommage des marques. Ou en fait moi, je râle souvent sur les gens qui oublient de mettre un H majuscule à GitHub ou en majuscule à JavaScript. Mais quand on fait des partenariats avec des gens qui font des bases de données, par exemple Elasticsearch, Elasticsearch, ça s'écrit en un seul mot, il n'y a pas de S majuscule. Et vu qu'on fait un partenariat avec eux, il faut qu'on aille voir dans le partenariales les comment s'appelle les guidelines de leur branding et être certain qu'on l'a bien respecté, quoi ? Mais typiquement sur Elasticsearch, c'est au dernier moment qu'on est repassé un peu partout. On s'est dit Ah mince, on n'a pas fait bien correctement et on est repassé dessus.

- Hélène : Ouais, mais c'est problématique de cohérence ou de consistance, comme on l'appelle aussi moi ce sont aussi des choses qui au quotidien font vraiment beaucoup partie de mon quotidien. Et c'est vrai que la première chose à laquelle on peut penser pour résoudre ça, ça peut faire partie d'un design system ou non, mais en tout cas, il doit y avoir des liens entre cet élément là et le design system. C'est, comme tu l'as évoqué, un dictionnaire, un glossaire, un lexique. On peut l'appeler comme on veut, mais c'est essayer de documenter. Déjà, par exemple, qu'est-ce que ça veut dire une application où est-ce que c'est utilisé ? Et est-ce qu'il y a des synonymes, par exemple les synonymes à éviter ? Ça, c'est hyper important parce qu'on définit quelque chose, parce que c'est, mais aussi parce que ça n'est pas. Et ça, ça aide beaucoup les personnes qui réutilisent après ce document là pour pour travailler de manière autonome et prendre des décisions éclairées sur lesquelles on n'aura pas besoin de revenir, nous, après. Donc, c'est un premier élément qui est hyper, hyper intéressant et ce dictionnaire/glossaire/lexique, c'est important qu'il soit partagé aussi. Mais ça, ça peut avoir l'air très simple, comme je l'évoque. C'est aussi un vrai travail d'embarquer les gens aussi sur ce travail là, il ne faut pas le faire tout seul. Parce que c'est vraiment un travail hyper collaboratif. En fait, si on change quelque chose, il n'y a pas de scripts qui existent pour le changer dans la tête des gens. Il faut les habituer aussi à consulter. Avoir cette habitude de consulter des documents là ou, a minima, d'aller regarder dans l'expérience à quel autre endroit ça peut être utilisé. Au moins ça, si le glossaire n’est pas en place, au moins un peu regarder ce qu'il y a en prod et essayer d'être cohérent. Car un utilisateur, vu que ce sont des parcours, ce ne sont pas juste des écrans séparés les uns des autres, c'est vraiment des parcours. Ce sont des choses qui peuvent introduire de la confusion et entachée du coup à terme, la rétention, l'usage du produit, ce qui encore plus à terme va être du coup néfaste aussi pour moi, pour le business

- Cécile : Et même sans même parler des utilisateurs en tant qu'équipe. Je trouve que quand on parle tous de la même chose, mais en le nommant par des choses différentes, en soit, on se comprend même plus. Et moi, je le vois en ce moment. On a un terme, on l'appelle soit une fois sur deux oon l'appel “rendez-vous” et d'autres fois, on l'appelle “événement”. Et plus personne ne sait si on parle de la même chose et on a une inconsistance totale.

- Hélène : Et ce n'est pas facile parce qu'on le voit bien. Et après la question, c'est bon. Alors, qu'est-ce que j'ai comme éléments qui vont permettre de choisir ? Après, comment est-ce que je vais documenter ça, le communiquer ? Et c'est-cette partie là qui est la plus fun ? Mais c'est vrai que ça occasionne, je pense, beaucoup de questions et de frustrations dans le quotidien. Quand, en fait, on n'utilise pas les mêmes termes, on se comprend moyennement et pareil, ça fait perdre du temps aussi.

- Hubert : C'est c'est marrant parce que moi, c'est une problématique que j'ai découverte avant Clever Cloud, je travaillais pour OpenDevise, donc c'est les gens qui maintiennent qui doktor et entoura des outils autour de la documentation. J'ai appris plein de choses : avant je savais écrire vite fait des readme, après j'ai compris ce qu’était l'architecture de l'information, penser comme un éditeur d'un bouquin, mais pour un site de doc. Et on en reparlera peut-être après. Est-ce qu'on tutoie les gens ? est-ce qu'on vouvoie les gens ? Quel est le ton ? Et c'est là que j'ai aussi appris cette histoire de OK, tu parles de tels trucs techniques, mais parfois tu appelles ça modules, parfois tu appelles ça package, parfois tu appelles ça bundle. Ok, c'est la même chose, c'est pas la même chose ? Comment tu gères ? Et je sais que là, moi, je vais pas tarder à essayer de mettre en place un système de dictionnaire, glossaire. On en a pas mal discuté chez nous et je vois le truc dans Ma to do liste. Et je suis là, ok. Par quel bout commencer ? Par quel bout j'attaque ça, et autant je vois à peu près quoi faire sur le on va passer partout et essayer de lister l'existant déjà. Et là, on parle de composant design system, mais bien entendu, il y a la documentation. Il y a le site web, l'aspect un peu vitrine, les supports marketing qu'utilisent les commerciaux. Il y a le code aussi. Est-ce que ça s'appelle pareil dans les classes, dans les bases de données ? Et là, on a de l'existant qui n’est pas toujours bien. Et du coup, je vois à peu près comment tracer l'existant. Après, comme tu le disais, il y a la conduite du changement avec les collègues. Si on décide d'uniformiser tel nom, il faut éduquer les gens à ce nouveau dictionnaire, etc. Et moi, je me demandais ce qui me parait le plus difficile, c'est, si tu veux vraiment décidé d'uniformiser un terme. Côté utilisateurs, comment fais-tu la conduite de changement sur ta base d'utilisateurs ? Nous, on a des utilisateurs qui sont là depuis 10 ans ? Donc, si on leur dit “on dit plus application, on dit runtime”. Comment fait-on pour pas qu'ils se perdent ? Ça, je suis perdu.

- Hélène :Yes ! Très bonne question et ce qu'il faut se poser aussi en se posant cette question, c'est à qui on s'adresse et comment est-ce qu’en fait, les nouveaux termes par exemple, qu’on va employer sur l'interface, sont aussi ceux qui sont employés par nos utilisateurs ? C'est vraiment hyper important de baser ces changements là sur les personnes à qui on va s'adresser parce que sans ça, ça sera vraiment assez difficile de leur faire adopter des mots sortis ex-nihilo de parce que telle ou telle problématique que nous, on a rencontrés dans notre quotidien, ça, les utilisateurs, c'est pas du tout leur problème. Et c'est pour ça que c'est intéressant d'aller soumettre ces nouveaux termes à des utilisateurs. On n'a pas forcément besoin de passer par un process ultra complexe et lourd, même si plus on est carrés sur le process de tests, plus c'est intéressant. Mais déjà, dans un premier temps, de le soumettre à des gens qui sont autour de toi ou que tu côtoie, qui se rapprochent en fait de ta cible de tests utilisateur et voir un peu ce que ça génère comme réaction. Ce que ça évoque, c'est déjà un premier point qui est assez intéressant à regarder pour être sûr de ce qu'on fait, en tout cas pour avoir des premiers éléments de réponse.

Ça, c'est vraiment hyper important. Après, on sait très bien que même avec les meilleures intentions du monde, quand on fait bouger, quand on change quelque chose dans des interfaces bas, parfois, ça peut être assez mal perçu par nos utilisateurs parce qu'on est habitué à un certain fonctionnement qui peut être imparfait, mais avec lequel on a ses habitudes. Et là, on bouleverse des habitudes. Donc, c'est toujours un peu sensible, mais il faut être bien conscient de ça et du coup, essayer d'accompagner ces changements là en fonction de l'importance du terme. S'il est vraiment hyper stratégique, ça peut être intéressant de l’accompagner d'éléments d'explication. Je pense par exemple, si nous, on décidait de changer un terme, j'en sais rien. J'essaye de trouver des exemples, mais vraiment, qui est au cœur de l'expérience, ça pourrait valoir le coup de l'expliquer, soit sur un article support, sur le blog. Là, je dis vraiment dans des idées un peu à vau-l'eau qu'il ne faut pas forcément prendre en compte. Mais ça peut être intéressant d'accompagner ça aussi par des explications. Globalement, et être conscient que ce n'est pas toujours simple. Mais si, à minima, on est sûr que ce terme là, il est compris. Alors déjà, on évacue un certain nombre de questions et problématiques qu'un changement peut supposer.

- Cécile : J'avais une petite question : c'est un truc qui m'est arrivé la semaine dernière, notre produit a changé de nom. Voilà, un jour, quelqu'un s'est réveillé en disant “On va vous changer le nom du produit. Donc, avec tout ce que ça implique derrière. Et ça, comment tu peux le gérer d'un point de vue content, au global, ce n’est pas juste changer un nom.

- Hélène : Ben c'est intéressant. J'ai jamais été confronté à cette problématique là.

- Hubert : Je peux te couper, Hélène. Ta société avance appeler le Site du Zéro et je me demandais si ty était déjà là à cette époque là.

- Hélène : Non, non, non, je n'étais pas là, je n'étais pas là, ça date. Je crois que, justement, il y a des éléments un peu interdits maintenant. “Zozor”, par exemple, qui était un peu la mascotte du Site du Zéro. Pas interdit, en effet on peut toujours l'utiliser avec un peu d'humour, mais en tout cas dans nos communications officielles et publiques, ce sont vraiment des éléments à bannir. Mais nos utilisateurs, enfin, ceux qui sont avec nous depuis hyper longtemps, ils nous appellent beaucoup. On peut voir ce nom là toujours apparaitre rapidement, même dans des vidéos qui parlent de nous sur YouTube ou des articles souvent openclassroom. Vous êtes introduit comme l'ancien site du zéro. Après, c'est un héritage, pense qui dans ce cadre là, qui est fondateur dont on peut, je pense, être assez fier. Donc ce n'est pas non plus. Ça fait partie de l'ADN de la marque. Dans un autre cadre, c'est vraiment un changement de nom. Ça doit être bien d'accompagner, préparer, planifier, communiquer. Bref, plein de verbe et “er” mais c'est vrai que c'est un sacré chantier. Pour le coup, chez Openclassroms, je ne sais pas comment ça s'est passé à l'époque. Je crois que c'était en 2012 ou 2015 sans être complètement sûr, mais dans ces eaux-là, ça fait un moment maintenant. Du coup, ça fait une dizaine d'années, les traces ont eu le temps de se diluer un peu. Mes conseils pour résumer. Déjà, comment ce changement est justifié. À partir de là aussi, ou bien dans le design, ça se justifie aussi si on a les bonnes raisons. Il faut être enthousiasmé par ce changement là. On ne l'est pas toujours, encore une fois, puisque c'est du changement. Il y a tellement d'occurrences, j'imagine, dans la plateforme où l'ancien nom est affiché. C'est en base de données, ça doit être un sacré et c'est tout ce que nous on a ces questions là. Quand on change un mot typiquement comme moi, on me le dit “là, Hélène, c'est hyper tard, ça a généré plus de taf.” Et maintenant, j'essaie de travailler sur comment est-ce qu'on s'assure que ce changement, ils interviennent. En tout cas que l'étude du bon mot, il intervienne avant qu'on construise les tous les éléments. Mais je n’ai pas de conseils très précis.

- Cécile : C'est qu'on est d'accord que changer un mot sur une maquette, c'est facile. Le changer en développement, c'est un peu plus compliqué.

- Hélène : C'est en fait, ça dépend du type de mot dont on parle. Si c'est un mot qui est, par exemple, qui décrit un qui est un rôle sur la plateforme. Là, c'est un mot cœur. Clairement, le changer, ça va être beaucoup de boulot. Si c'est une formulation qui veut améliorer, là, on peut avoir des outils de gestion de chaîne, de traduction. Nous on utilise Phrase par exemple, ou là ça peut être plus simple. Une recherche, on regarde toutes les occurrences de ce mot là et là, on peut changer. Mais ouais, si c’est un mot coeur, c’est plus compliqué. Et le nom du produit, de la marque, du service, c'est clairement un mot cœur.

- Cécile : Nous, la problématique est qu'on a une application, une webapp et une application native sur mobile. Et après, il y a tout ce qui est lié à la FAQ. Avec toute la communication autour et les personnes qui font notamment les vidéos de tutos, etc. ont du tout retourner.

- Hubert : C'est pas le sujet du jour, mais ça va poser des gros problèmes de SEO aussi. Tous les gens qui te cherchent particulièrement sur les stores Apple et autres, ça ne doit pas être simple non plus. Bon, bon courage à vous.

- Hélène : Puis, comme tu l'a évoqué, il y a un nombre de supports FAQ, mais auquel on pense pas toujours en plus. Et puis, on en retrouve toujours des petits bouts à droite, à gauche qu'on n'a pas, auquel on n'a pas pensé. Mais là, justement, sur ces changements, on ne l'a pas du tout encore fait dans le design system, mais j'ai commencé à discuter un peu avec Christophe de Cantaloup, qui est qui s'occupe de l'équipe fondation, donc design system et il faut qu'on étudie un peu la manière dont on pourrait faire fonctionner ça. Mais ce serait intéressant d'avoir cette vision un peu macro des usages d'un mot et on change à un endroit, comme un composant, en analysant bien les impacts en amont. Mais qu'on puisse répercuter ces changements là si le changement est documenté, justifié et qu'il apporte de la valeur. Mais bon, ces discussions qui sont vraiment aux prémices, mais ce serait chouette qu'on puisse le faire. Et donc ça pose la question après du lien avec les clés, des clés de traduction qui servent à appeler le contenu. Mais c'est des questionnements qui sont assez intéressants là dessus.

- Hubert : J'ai hâte d'assister aux retours d'expérience quand ça sera terminé

- Cécile : Tu parlais de clés de traduction, est-ce que vous pouvez expliquer, Hubert, tu as l’air de savoir ce que c’est.

- Hubert : Alors nous, on n'utilise pas d'outils. Est-ce que tu peux répéter l'outil que vous utilisez ? Phrase ?

- Hubert : Ok. Et du coup, oui, la question des clefs. En fait, quand on écrit une application, un site web. Je ne sais quoi en avec plusieurs langues. Alors en plus, on parlera potentiellement plus exactement de plusieurs locales. C'est tout un sujet et on va en général dans le code à un endroit où on a besoin de mettre du texte. Faire appel à une fonction, ça dépend des systèmes et cette fonction lui dit à tel endroit, je veux mettre le texte qui dit bonjour et bienvenue sur l'application. Et en général, on va identifier que c'est-ce texte là et pas le texte qui dit “Êtes vous sûr de vouloir supprimer votre compte ?” On lui donne une clé, un identifiant qui est qui est souvent du texte. Souvent, c'est de l'anglais et souvent, c'est un peu une sorte de label descriptif assez court. Enfin, après, ça dépend et donc typiquement dans les exemples un peu nuls que je viens de citer, ça serait le” welcome pour message” ou le “Delete count confirme”. Un truc dans ce genre là. Et donc ensuite après, il y a énormément de manières de faire.

Tu vas faire correspondre une clé de traduction à un vrai texte qui est disponible dans les différentes langues que tu supportes. Et donc, c'est là que tu vas avoir, soit des fichiers de traduction dans ton code, soit carrément une connexion avec un outil tiers. Donc, la peut-être Phrase qui permet de donner une interface un peu sympa à des professionnels de la traduction pour implémenter tout ça. Et on en parlait un peu en off. Déjà, choisir les bons termes, c'est un métier. Choisir les bons termes dans les autres langues, de traduire. C'est un autre métier. Mais même bien choisir les clés de traduction pour que dans le code, tu t'y retrouve, que si tu ré-utilise des clés à plusieurs endroits, que tu puisses le faire au mieux. C’est aussi une question à mettre en place pour ne pas faire n'importe quoi et clairement. Si tu mets rien en place, ça devient n'importe quoi. C'est de l'en tropisme. C'est qu'une question de temps avant que tu ne t'y retrouves plus dans tes clés de traduction.

- Hélène : Est-ce que l'enjeu de la clé, c'est que ce soit assez précis pour savoir ce à quoi ça fait référence où est-ce qu'on se trouve dans l'interface, mais en même temps pas trop précis pour que si on change le contenu à l'intérieur, le nom de la clé fasse toujours sens malgré tout, c'est une gymnastique. Nous, pour être complètement honnête, on fait au max, mais l'idée, c'est pas qu'on passe trop de temps non plus à écrire les clés, parce que c'est pas du contenu user facing, vraiment le focus, il est là dessus, mais en même temps, il ne faut pas non plus que ce soit complètement délaissé parce que c'est hyper important pour avoir un cadre de travail bien organisé. Et quand on a un changement à faire quelque part, qu'on puisse s'y retrouver dans l'écrit. Typiquement, nous, on essaye de finir le nom de la clé en fonction du contexte, mais par le nom du composant, ce qui permet de savoir où est-ce que, quel type de contenu est affiché ? Ça a ses avantage, dans le sens où si, par exemple, on change la manière d'écrire, nous, snackbar, donc ce sont des petits messages de validation après une action qu'on peut retrouver en bas de l'écran, si on change la manière dont on veut les écrire, moi, si je tape snackbar dans Phrase, je peux les retrouver. Par contre, si par exemple, avant on avait un bouton, on utilisait le composant bouton pour afficher ce type de contenu là et que après, ce serait un texte link. Enfin un lien. Du coup, ça fait beaucoup moins sens. Chaque, chaque clé, elle peut être assez fine si on veut vraiment une clé ultra générique et en même temps spécifique. C'est une vraie gymnastique dont il faut aussi s'accorder le fait que ce ne sera pas parfait, mais faire au mieux. Avoir des guidelines d'écriture. Et ça, c'est-ce qu'on a mis en place il y a un peu de temps. On a en gros, on a la FAQ Phrase et du coup, on a pris un peu de temps pour. Moi, j'ai pris le contenu qui m'intéressait et je l'ai adapté à notre process et à notre usage. Comme ça, on a vraiment ces ressources là et c'est-ce qui nous a permis, nous, en tant qu’UX writer, de sortir cet élément là de notre scope. Avant, c'était que nous qui écrivions les clés, ce qui voulait dire qu'on était sur tous les projets, sauf qu'on était beaucoup moins nombreuses. Donc, c'est là où le serpent se mordait un peu la queue. Et donc, on a mis des guidelines, des outils pour rendre les gens aussi autonomes sur ça. Et que ce ne soit pas trop le bazar.

- Hubert : Non, mais je dis ça car qu'on a deux systèmes actuellement et l'ancien, il y a des mots, il y a un seul mot il est en majuscule, il est hyper générique. Il y a d'autres trucs où il y a des préfixes séparés par des points où on comprend un peu mieux où est-ce que ça pourra être utilisé. Et donc, il y avait un peu de tout dans cet ancien système et dans le nouveau qui est uniquement utilisé sur notre bibliothèque de composants. On a un peu comme toi des suffixes, mais nous, c'est des préfixes par composant et pour l'instant, on ne partage pas les traductions entre les composants. C’est peut être un truc qu'on modifiera. Par contre, ce que je trouve génial et je ne l'avais jamais eu avant, dans d'autres projets, c'est d'outiller la vérification. Et donc ça sort peut être un peu de l’UX writing, mais à n'importe quel moment, je suis capable de savoir qu'il y a des traductions qui existent, dont je ne me sers pas, qu'il y a des composants ou j'essaye d'utiliser des clés qui ne sont pas traduites. Et puis, j'ai aussi un petit tips pour savoir si du texte que je vois actuellement est pas codé en dur ou s'il passe bien par le système de traduction. Et en fait, avant, je n'avais pas ça, et depuis que j'ai ça, je vais tout le temps vouloir ça sur le reste de ma carrière. C'est vraiment plus safe.

- Cécile : Et c'est clés du coup, aujourd'hui, tous les deux avez des projets en français et en anglais.

- Cécile : Et si on devait, par exemple, imaginer gérer des langues qui ont un sens de lecture différent ?

- Hubert : Moi, j'ai jamais eu à le faire et ça me fait excessivement peur. C'est une vraie compétence. Mais même en tant que développeur, parce que quand tu commences à écrire en arabe, en hébreu,en je ne sais quoi, je ne lis aucun des deux, donc, même si je suis face à l'application qui est traduite. Et puis même, ça change vraiment toute l'interface. Si vous avez déjà utilisé Tweeter, vous avez déjà vu quelqu'un qui l'utilise dans une langue qui est en right to left et tout est inversé dans les menus.

- Hélène : C’est un sujet quii se prépare pour le coup. Et puis voilà, comme tu le disais, ce sont des compétences, c'est un vrai boulot. C'est quelque chose qui se prépare et qui demande du temps. Parce que pragmatiquement, on peut juste penser, il y a une barrière. “On ajoute une locale.” Mais en fait, comment est-ce qu'elle est gérée la pluralisation ? Est-ce qu'elle permet de prendre en compte des manières de gérer le pluriel dans d'autres langues ? Parceque toutes les langues ne fonctionnent pas de la même manière. Par exemple, Children, enfin, je sais pas comment l'expliquer clairement, mais on va avoir des chiffres qui vont. Par exemple, le 0 en anglais nécessite un s, le 0 en français, non. Ça dépend des cas, on peut en avoir un. Mais globalement, il n’y en a quand même pas. Et tout ça, c'est des choses qui doivent être prévues. Et quand on change le sens de lecture, c'est autre chose encore que oui.

- Hubert : Mais c'est marrant, j'allais parler des pluriels aussi, qui est avec les dates et les nombres, le petit truc est toujours un peu embêtant, surtout quand tu commences à avoir des phrases traduites qui sont variabilités. Par exemple “Il vous reste 5 jours pour valider votre compte”. Alors on a tous triché, on a mis 5 jours avec un s entre parenthèses. Et c'est vrai que maintenant que j'ai l'outillage, nous, dans nos composants, pour pouvoir le viabiliser, je le fais. Mais il y a aussi et je viens de perdre ce que j'étais en train de dire, les pluriels ? oui ! Et en fait, utiliser le terme local. Nous, actuellement, on a du français et de l'english, mais on a l'anglais britannique, de l'anglais américain un peu partout, parce qu'on fait tout de même et que l’on n’harmonise pas encore correctement les choses et qu'on n'a même pas tranché si on voulait mettre des Z ou des S. Et puis d'ailleurs, on en parlait en off, mais je sais jamais lequel est British English, lequel est american english. Mais ce n'est pas simple.

- Hélène : Alors si je me souviens bien en le s, c'est le British et le Z, c'est US. Mais j'espère que je ne dis pas de bêtises, je vais me faire taper sur les doigts. Mais, ça, c'est une première décision à prendre en fonction aussi de la vision de l'entreprise. C'est quoi les marchés qu'on veut avoir ? Et c'est quoi notre base d'utilisateurs actuels ? Elle se connecte plutôt dans quel pays ? Et là, c'est en ayant ces deux éléments là, la décision elle peut être plus simple à prendre là dessus. Après, voilà, si on laisse passer des Z ou S en fonction du choix, je pense que ça sera toujours compris. Mais déjà, peut-être avoir ce premier choix là dans la langue c’est intéressant. Nous c’est un des premiers trucs qu'on a acté, c'était plutôt accepté par tout le monde. Mais voilà, on l'a documenté. Ça y est, on n'y touche plus et ça n'a jamais été remis en question. Et ça permet aux gens de savoir. Mais là, récemment, je crois qu'il y avait quelqu'un qui m'avait dit “Ah, mais je sais jamais”, la même question que toi. Mais ça veut dire que la décision, elle, n'a peut être pas été encore suffisamment communiquée. Donc, c’est intéressant aussi de prendre ce feedback là. Mais l'avoir quelque part, être sûr d’avoir les bonnes raisons. Encore une fois, être en mesure de justifier, de rationaliser les décisions, c'est toujours ce permet de backer les choix qu'on fait.

- Hubert : Et puis, je viens de prendre l'exemple de l'anglais, mais enfin, c'est bête, mais on va rappeler une énième fois que le français n'est pas que la langue de la France, loin de là, et que si demain on recrute, je ne sais pas combien d'équipes en Afrique, en Belgique, en Suisse, au Canada ou je ne sais où. On a pas tous la même manière de faire les choses. Je sais plus quelle règle dont je ne peux pas donner l'exemple, mais ce n'est pas une histoire de pluriel, c'est une histoire de nombres ou de dates, où au Canada, au Québec, ils ne font pas comme nous. Et c'est bête, mais c'est des petits détails comme ça, il faudra que j'essaie de retrouver l'exemple,

- Hélène : Mais qui peuvent du coup complètement transformer une expérience parce que, par exemple, si on prend un rendez-vous en croyant le prendre à telle date en le 07 02 alors que c'est le 02 07, tout de suite, si on inverse le jour et le mois,c'est beaucoup plus compliqué. Donc c'est hyper facile comme tu dis, ce sont des petites choses, mais qui on un impact qui peut être vite, très, très important.

- Hubert : Moi, je triche. J'ai un public de développeurs développeuses, de gens qui bossent dans la tech. Donc il y a beaucoup d'endroits où on écrit des dates en ISO, donc en année, tiret mois, tiret jour et on triche un peu avec ça. Du coup, c'est un peu universel, entre guillemets, dans le monde de la tech, mais on ne peut pas tout le temps le faire, sur les factures, on peut pas le faire,

- Cécile : Mais même sans parler même de traduction, par exemple, les règles typographiques en français n'ont rien à voir avec les règles typographiques en anglais. Et je sais qu'une des règles assez basiques où je fais la guerre, ce sont les capitales accentuées. Ou même la différence entre une capitale et une majuscule.

- Hélène : Ce qu'on essaye de mettre en place, c'est un réflexe, des habitudes, documentées, des choses. Et on sait qu'on a tous des compétences orthographiques, grammaticales et lexicales qui sont différentes. Donc ce qui dit ce qui est important, c'est d'essayer de mettre en place des garde-fous. Typiquement, là, on essaye d'analyser des plugin Figma correcteurs qui permettent de corriger, de faire des corrections orthographiques. Ce qu'on aimerait à terme, c'est avoir quelque chose un peu plus massif qui permette de corriger aussi des Google Docs, d'avoir le glossaire aussi dedans. Vraiment d'aider les gens à écrire de les emporter, ce terme très à la mode. Mais voilà de leur donner aussi les outils et pas que ça génère de la frustration. Parce que il y en a pour qui l'orthographe, ils ont des compétences, tout simplement, et qui les ont acquises. Et c'est très cool, mais pas tout le monde. Il faut le garder en tête, ne serait-ce que, par exemple, la dyslexie. Ces choses-là. C'est important aussi d'être, je trouve empathique là dessus afin de garder en tête que voilà, encore une fois, il y en a qui qui arrivent très bien et moi, je travaille avec des gens qui ont de très bonnes, très, très bonnes compétences orthographiques, même meilleures que moi sur certains point, et d'autres beaucoup moins. Et l'idée, c'est de contenter un peu ce qu'on connaît moins et de les aider.

- Cécile : Je sais que je suis une quiche totale en grammaire, orthographe, conjugaison. Et le sachant, c’est quelque oùje suis très transparente avec les équipes avec lesquelles je travaille. Je le dis en fait, relisez-moi, n'hésitez pas à corriger, etc. Par contre, à côté de ça, et vu que j'ai de formation de maquettiste, j'ai été dressé aux règles typographiques. C’est un peu les deux côté

- Hélène : Et la rigueur, oui. ce que tu évoques, c’est aussi de la rigueur qu’il faut. Et puis, on voit une faute d'orthographe sur une interface, mon Dieu, enfin tout de suite, la crédibilité, elle en prend un coup, mais sévère. Et c'est le drame en interne. Mais ça arrive. Et ce qu'il faut c'est minimiser au maximum ça et donner les outils pour que ça arrive le moins possible. On n'est pas infaillible. Moi, quand je passe une journée à refaire, faire, refaire, réécrire, au bout d'un moment, je vois plus rien et je peux laisser passer des trucs aussi. Et donc, il me faut des garde-fous et l'oeil extérieur même quand on est bloqué sur un élément de copie, on sait pas comment le formuler. C'est aussi le soumettre à quelqu'un, le dire à voix haute. Il y a des petites techniques comme ça pour débloquer aussi ces situations là et encore une fois en un. Les autres, je pense que ça les sort aussi un peu de leur tache. L’idée ce n’est pas de noyer les autres, ce sont des demandes. Mais sur ça, je pense que sur la copie, c'est intéressant d'avoir toujours un point de vue externe

- Cécile : Et même prendre du recul. Le faire toujours en deux fois, avoir une première fois où tu le fais et tu reviens le lendemain. C'est comme quand on écrit des articles et qu'on se rend compte qu'on a fait des phrases qui font 300 mots.

- Hélène : Mais oui, et puis moi, ça m'arrive aussi souvent d’avoir écrit quelque chose, donc on a fait le process, on arrivait à la fin du process. Le design final, la copie finale, tout est prêt. Je le vois sur notre outil de pré production et là, je me dis “Oh là là, mais est-ce qu'on est sûr vraiment ? Pourquoi j'ai pris cette décision là ?” Et l'idée, c'est aussi est-ce que j'ai bien documenté le pourquoi des décisions ? Pas trop, mais en même temps suffisamment pour que je sache pourquoi j'ai fait ça et ce sont des itérations et on peut améliorer. Il faut se dire aussi que ce n'est pas gravé dans le marbre et qu'on pourra y revenir. Et l’idée, c'est de prioriser aussi ces changements là. Mais voilà, ça arrive souvent de pas être toujours ultra satisfait, mais il faut l'accepter.

- Hubert : Et si je peux me permettre une petite anecdote avant que tu enchaines. Est-ce que vous avez des collègues qui, quand vous leur dites, “tu savais qu' avant deux points ou un double signe de fin, notamment à deux points, il fallait mettre un espace insécable ?” etc. Et eux, ils te répondent, tu veux dire une espace insécable ou qui viennent vraiment chipoter ce genre de détails ? Non, parce que moi, j'en avais un et. Et c'est vrai qu'il nous aidait beaucoup sur tous ces petits détails.

- Hélène : Mais tu vois, une espace insécable. Je ne le savais pas. Je n'ai jamais entendu ça. Mais ce qu'il faut, c'est être sûr que ce que les gens lisent et tu parles d'espace insécable, mais typiquement, ça, c'est un truc vachement garder en tête aussi, pour pas que sur différentes tailles d'écran, ça se balade un peu n'importe comment, pour que ce soit plus lisible. Mais nous, on est toujours, il faut respecter les règles orthographiques, mais jusqu'à un certain point. Et aussi, il y a un point qui est très important en UX writing, c'est, si la règle orthographique va générer des questions ou faire tiquer des gens. Encore une fois, il faut que le choix soit bien pesé, mais on peut aussi s'autoriser à la contourner. A dire bah non, on la suit pas. Enfin, c'est encore une fois à qui on s'adresse ? Pourquoi on le fait ? Et comment est-ce qu'on va faire en sorte que cette expérience, elle ne va pas générer de blocages, de frustrations, de questions inutiles ? On est tous là pour passer le moins de temps possible, mais réaliser des actions. Et nous, notre rôle, c'est de faire en sorte que ce soit le plus fluide possible. Donc c'est juste enlever de la friction. Et si c'est pour en rajouter en respectant des règles sorties de je ne sais quelle édition de l'Académie française de 1755, franchement, on a tous d'autres chats à fouetter.

- Cécile : C'est marrant à ce que tu dis, mais on parle de règles, de grammaire, etc. Mais on on peut faire aussi en lien avec ce qui est lié à l'écriture inclusive. Parfois la grammaire et l'écriture inclusive, ça ne marche pas toujours très bien. Alors que c'est positif,

- Hubert : C'est marrant parce que je ne réponds pas directement sur notre bibliothèque de composants, mais donc je disais j'ai un collègue et un nouveau qui vient d'arriver cette semaine, donc on l'a recruté à un moment donné, enfin d'année dernière. Et donc, j'ai écrit l'offre d'emploi qui était en français. Je triche, je ne cherche pas un développeur/développeuse, voire un truc que moi je trouve encore un peu plus triché, à savoir développeur entre parenthèses H/F, je vais dire oui, ok, ça valide la loi, mais c'est un peu cheap. Je vais utiliser des mots épicène comme personne. Je cherche une personne qui fait du développement web, etc. Dans l'interface, c'est assez rare chez nous qu'on ait besoin de rentrer là-dedans. Il y a potentiellement parfois ou on va parler d'utilisateur d'utilisatrices, mais je n'ai pas de souvenir que ce soit. Enfin, on va parler, on devrait parler, mais je n'ai pas de souvenir qu'on est de qu'on ait tant de cas que ça à gener en terme de jeu de mots. Par exemple, en ce moment, on va refondre un truc qui affiche des membres. Un membre, ça va, ça passe. Mais je sais qu'un peu de la même manière que j’ai tendance à dire le covid. Même, si je ne sais qui je ne sais où, a décidé qu'il fallait peut-être dire

- Hubert : Je ne sais pas combien de mois après que finalement, tout le monde disait “le”, donc ça n'a aucun sens. Enfin, bref, c'est un autre sujet. Mais j'aurais tendance à utiliser l'écriture inclusive avec des mots épicène, potentiellement de la répétition de mots. Et dans nos interfaces à nous, j'aurais tendance à éviter des points médians, mais la question ne s'est jamais posée. Elle ne ne sais pas encore posée, on va dire, mais c'est vrai que dans mon offre d'emploi, j'en ai mis un. J'ai mis un point médian à un moment. Parce que je vais préférer essayer de pas générer, je sais pas si je peux dire sur le podcast là, mais je vais essayer de pas générer des gens qui vont dire “gnagnagna, vous avez fait ça”. Et en même temps, essayez d'avoir quelque chose le plus inclusif possible parce que parce que plein de raisons, enfin, c'est juste normal. Je sais pas comment le dire, mais non, n'a pas trop eu de de cas et en fait. Et j'imagine qu'Hélène tu diras la même chose. C'est beaucoup plus facile en anglais.

- Hélène : Complètement. Franchement, très bonne transition. En anglais, on peut utiliser le ZET. Donc, si c'est pas une langue latine, du coup, et ça nous permet, nous, c'est-ce qu'on fait. On l'a documenté dans le design system. Et ça s'applique dans notre cas, donc beaucoup plus simple. Je n'ai pas de phrase là qui me vient, mais voilà, au lieu de il/elle h/she, ça sera then/there, etc. En français, langue latine qui est beaucoup plus compliquée et j'étais tombé sur un thread de tweeter, on tortille quoi. Il n'y a pas de solution parfaite. Typiquement, le point médian, les parenthèses sont mal lues par les lecteurs d'écran. Après, la question peut se poser : est-ce qu'en l'utilisant, on permettrait, enfin, on peut forcer aussi les outils à s'adapter. Ce n'est pas tout le temps à nous de minorer aussi les expériences pour ça. Mais nous, on l’avait utilisé, je n'y étais pas encore, mais Nora, qui travaillait chez Openclassrooms à l'époque, avait étudié ça à un moment. On mettait, je crois que c’était le point médian partout. Et elle avait posé la question à des étudiants et des étudiantes, du coup. Et la décision avait été suite à ses réponses de le supprimer et de rester sur soit des mots épicène, donc des mots qui ne sont pas genré ou du masculin générique.

Donc, on sait très bien, enfin, que le masculin l'emporte sur le féminin. C'est une règle qui est assez assez difficile à avaler. Donc c'est pas terrible, mais nous, en gros, côté anglais, on a les règles pour l'anglais, on a un autre onglet pour l'inclusion côté Français ou là, on a essayé de trouver des tactiques, par exemple, plutôt que d'utiliser étudiants, on va appeler une variable avec le prénom de l'étudiant. Privilégier le fait de s'adresser à un ensemble : la communauté étudiante, par exemple, ou là, on présume que c'est pas d'un genre, d'un autre ou etc. Donc, il y a une liste comme ça de petites astuces. Et à la fin, parce qu'il y a des cas où il n'y a pas de solution, on indique de privilégier le masculin générique aussi pour la compréhension. Ce qu'il ne faut pas non plus que, moi, j'avais fait le test sur des formulations qui étaient au masculin d'essayer de trouver l'équivalent plus inclusif. Et au final, on comprenait pas forcément de quoi il s'agissait. Parce que c'était tellement tourné, retourné, tortillé que c'était plus compréhensible. Mais après, je pense que c'est aussi une question d'habitude. C'est peut être moi aussi, mon biais à moi qui fait je trouvais que ce n'était pas forcément le plus compréhensible, alors qu'en fait, ça l'était. Donc, c'est une vraie question. En tout cas, nous, dans les interfaces, on a souvent vu qu'on s'adresse à des individus directement. On parle de mentor, on parle d'étudiants, de tuteur, de tutrice, il y a beaucoup de rôles individuels comme ça qui sont genrés dans la langue, sur lesquels on essaie d'être le plus inclusif possible. Mais on ne l'est pas toujours, je le sais et on nous a fait la remarque sur certaines expériences, donc on essaye vraiment d'y apporter le plus de soins possible, ne serait-ce que dans les illustrations aussi sur lesquelles on travaille. La taille de l'homme, de la femme, qui est en position aussi d'être plus sachant, par exemple, d’être plus dans le rôle de la responsabilité. Tout ça, on essaye de faire vraiment très attention. Mais voilà, il y aura toujours, je pense, des choses à améliorer. Mais en tout cas, voilà où on en est et on l'a documenté dans design system parce que ça, c'est hyper important. C'est hyper important qu'il y ait une décision qui soit prise là dessus et que ça puisse être partagé.

- Cécile : Je vois sur l'écriture inclusive, sur un design system sur lesquels j'avais travaillé la. La première phrase que j'avais mis dans la documentation, c'est que l'écriture inclusive ne se résume pas juste au point médian. Ou le point médian n'est pas l'écriture inclusive et souvent, je trouve que quand on parle d'écriture inclusive, le principal problème, le challenge, ça va être d'éduquer les équipes à l'écriture inclusive. Il y a plein de manières de le faire. Tu disais, utiliser un vocabulaire épicène. À titre personnel, je trouve ça très bien, très riche, parce que ça nous oblige à chercher d'autres mots. On a une langue qui est très riche, donc autant aller voir d'autres mots, d'autres termes. Et il y a aussi, je ne sais pas si vous utilisez ça chez Openclassroom, les accords de proximité ?

- Hélène : Non, on l'utilise pas parce que ça, c'est pareil, mais c'est hyper intéressant comme pratique, mais ça peut créer un moment dans l'expérience où la personne se dit “mais c'est une faute” et du coup, c'est pareil. On choisissait d'utiliser la carte de proximité. Il faudrait que ce soit documenté et je pense communiquer aussi. Enfin, il y a vraiment un, mais vous vous l'utilisez du coup ?

- Cécile : Alors pas sur le projet sur lequel je suis aujourd'hui. Sur un projet précédent, on avait fait un gros travail sur la FAQ avec la personne qui travaillait sur le support. On avait écrit la FAQ ensemble, donc pareil, ça avait été un gros travail de Qu'est-ce qu'on met dedans ? Quels sont les termes qui sont utilisés par les utilisateurs pour rechercher et pour poser les questions ? Et on avait tous fait toute une liste de structures de phrases types, suivant quels types de problématiques on répondait et également de comment on écrivait de la manière la plus inclusive. Par contre ce n’était pas du tout parfait, mais c’est un truc que j'avais réussi à mettre en place, justement, les accords de proximité.

- Hubert : Alors qu'on est juste sur la page Wikipédia, ce que je ne sais pas ce que c'est.

- Hubert : Non, mais je lis à moitié sera plus simple si l'une de vous explique ce que c’est les accords de proximité. Mais moi, ça ne me dit rien.

- Hélène : Ben quand un groupe, plusieurs noms dans une phrase, par exemple, les étudiants et les étudiantes commencent. Non, alors là, ça ne marche pas. On commencer ? Je ne sais pas comment je passe ou ça marche. En plus, nombreux à plusieurs. Donc, tu as plusieurs noms de plusieurs genres, un masculin et féminin. Et si ton féminin, il est plus proche de ton verbe, tu vas l'accorder avec celui qui est le plus proche. Plutôt que de d'accorder à un ensemble, le masculin l'emporte sur le féminin est la règle généralement admise

- Hélène : Du coup, à l'écrit, autant à l'oral, ça ne s'entend pas, mais à l'écrit ou y aurait un ée par exemple.

- Cécile : Les étudiants, les étudiantes sont grandes, ça donnerait ça.

- Hélène : Enfin, il y a l'évangélisation à faire parce que ça accroche.

- Hubert : Ben, c'est un juste milieu. Je ne pense pas que le design system, que ce soit celui d'Hélène, la bibliothèque de composants, soit l'outil qui va aider la société à s'améliorer. Et en même temps, faut pas qu'elle soit un obstacle parmi plein d'autres à rester dans des vieux réflexes du patriarcat. Je pense que c'est mon point de vue.

- Cécile : Oui, après moi, il y aussi un truc, je pense. Je trouve qu'on bosse sur des produits essentiellement qui se lisent et qui qui se lisent dans nos têtes. Personne ne lit son interface à son voisin. Donc, ça participe aussi de l'éducation, d'avoir sur des choses qu'on lit. Après, ce sera plus facile aussi, peut être en les entendant derrière, si on a habitué notre cerveau à le lire. Et puis après, ça parle aussi de la responsabilité qu'on peut avoir aussi en tant que designer, en tant que développeur développeuse.

- Hélène : Moi, je pense qu'on a tous quand même une petite responsabilité sur les choix qu'on fait, la manière dont on communique, la manière dont on écrit, la manière dont on code. Il y avait aussi des questions sur master, par exemple. L'usage de master, ce sont des vraies questions aussi. Tout ça,

- Hubert : Je vais en parler. Là à l'inverse, c'est plus des terminologies qu'on a nous, on a beaucoup parlé de serveur. Donc on va avoir des master slave, des black list, tout ce genre de choses. Et j'avoue que je ne sais pas trop quel est l'existant dans notre documentation, mais on a des équipes qui sont sensibilisées à ces trucs là. En fait, là comme ça, je n’ai aucune idée de où on en est dans l'existant. Je sais qu'actuellement, si tu crées un projet chez nous, la branche principale Git s'appelle toujours Master. Je suis plus choqué par le terme slave que par le terme master. Mais bon, la limite, ce n'est pas forcément mon avis qui compte. Mais oui, non, il n'y a pas que que cette partie là, c'est tout un sujet de la bonne terminologie et d'aller dans le bon sens.

- Cécile : Ça fait quand même pas mal de temps qu'on discute avant qu'on se quitte. Je voulais juste parler d'accessibilité. Notamment dans tout ce qui est des alternatives textuelles pour les images, les descriptions d'images. Je ne sais pas si Openclassrooms, vous avez mis des choses en place, c’est quelque chose qui est très compliqué à faire : écrire pour des alternatives textuelles.

- Hélène : Il y a Morgan, qui a beaucoup bossé sur les alt des icônes, je ne sais pas si ça a été publié dans le design system, mais je sais qu'elles ont avec Adèle, une développeuse, travaillées toutes les deux ensemble et elles ont testé avec des lecteurs d'écran ce que ça donnait. Comment c'était entendu ? Il y a eu ce sujet là qui a été lancé. Moi, je me rappelle la première fois, c'est un développeur qui m'a dit “Hélène, là, dans la copie, il manque les textes d'accessibilité”. Aucune idée de ce que c'était, j’étais là “Bon Merci Nicolas. Je fais quoi ? Aide moi s'il te plaît.” Et eux, on les a fait ensemble, du coup. Et ça, c'était hyper cool. On ne l'a pas documenté, du coup, quand la question s'est reposée. Flute alors ! Le travail doit être pas refait parce qu'il y avait déjà des éléments. Mais bon, il faut cadrer un peu plus sur le sujet. Mais c'est des choses qui doivent être documentées et pas que dans le design system, dans le processus aussi. Là, je pense qu'il y a une question de process, pas faire en sorte que ça arrive trop tard et vraiment l'intégrer quand on design un composant, quand on design une expérience, il faut y penser. Je n'ai plus le chiffre, ce n'est pas forcément sur le handicap visuel, mais il y a quand même une énorme partie de la population française qui est considérée comme atteinte d'un handicap, quel qu'il soit. Donc, c'est vraiment des choses qu'on ne peut pas mettre de côté.

- Hélène : C'est énorme. On a eu une personne qui est venue chez Openclassrooms, on a eu une formation et cette personne était non-voyante et elle s'est mise à naviguer. Et en fait, c'était une mise en situation vraiment du réel, la réalité crue. Et là, on s'est rendu compte qu’on avait l'impression qu'on faisait bien. On fait bien, mais on ne fait pas encore assez. L'étendue du travail là dessus. C'est important. Mais encore une fois, si on se rend compte qu'il y a des manques et on s'en rend compte. C’est comme ça qu'on avance aussi.

- Hubert : Donc, comme tu disais, on les intègre au process, on essaye d'y penser. Nous, on a très peu dans nos composants d'images et dès qu'on a des icônes, elles ont le texte alternatif. C'est le texte qu'il y a à côté de l'icône en général, voir si le texte est déjà à côté affiché, on ne met pas de texte alternatif pour pas que ce soit redondant dans le lecteur d'écran. Et encore, je vous dis ça, moi, j'ai vraiment l'impression d'apprendre et d'être assez, je ne vais pas dire nul, mais débutant sur tous ces sujets là. Mais c'est vrai que récemment, on a eu sur le fameux composant qui affiche tout ce qui est grafana, on a mis des captures d'écran et on est arrivé dans les “ah bas oui, mais les textes alternatifs, il faut les traduire aussi”. Et puis, il ne faut pas juste mettre image 1, 2, 3 pour essayer de décrire ce qu'il y a sur l'image pour le lecteur. Enfin, bref, vous voyez ce que je veux dire, mais c'est vrai que j'ai jamais réfléchi au fait que ça nécessitait de les traduire.

- Hélène : Tout texte il y a une clé. Il y a la langue originale et si la langue est disponible dans d'autres langues, il y a là, il y a l'autre langue, donc le moindre petit label qu'on voit. Oui, et l'image qui les accompagne, c’est pareil.

- Cécile : Et puis même les alternatives textuelles, le piège, c’est que pour le SEO, c'est quelque chose qui est très important. Mais écrire pour du référencement et écrire pour des gens, c’est totalement différent. Donc je pense que des fois avec le marketing ou la communication, ça un peu coincer à ce niveau là. Bon, ben je pense qu'on va, je crois qu'on va devoir s'arrêter là si je pense qu'on a encore beaucoup, beaucoup, beaucoup de choses à dire sur ce sujet là, je sais pas si vous avez un petit mot pour dire pour la fin, je une petite conclusion, Hélène, Hubert ?

- Hélène : Oui, c'est hyper important quand on conçoit un design system de penser au contenu parce qu'il va être consommé en même temps que les actions. Et quand on a, on ne sait pas par où commencer. Ce qui est intéressant, c'est d'aller voir ailleurs ce qui se fait et de s'en inspirer. Vraiment, chez nous, on a commencé comme ça. On est allé voir plein de design system où on savait que les équipes contenu étaient plus matures. Donc typiquement Shopify, Adobe. Ils ont des design system qui s'appellent Spectrum ou Polaris, mailchimp a aussi des content guidelines qui sont très élaborés et souvent cités à raison. Et du coup, à partir de là, comment est-ce que ça peut s'appliquer à mon produit ? Comment est-ce que moi, je peux me servir de ça pour commencer à documenter des choses, fixer des premiers éléments ? Et voilà, c'est vraiment commencer par aller voir ce qui se fait ailleurs et essayer aussi d'avoir une petite visibilité la plus extensive possible, mais en tout cas de voir un peu comment on écrit en interne. C'est où que les problèmes les plus récurrents concernant le contenu se retrouvent. La cohérence, clairement, c'est je pense que c'est vraiment l'une des problématiques les plus frappantes en termes de contenu. Donc là, si c'est vraiment le plus prioritaire, le plus problématique, voilà. La première solution, c'est peut être de commencer, juste à noter le mot et sa signification. Mais voilà, petit à petit, essayer d'identifier des étapes et d'aller regarder ailleurs.

- Hubert : Ben moi, je vais rejoindre un peu ce que disait Hélène sur le fait d'aller voir ailleurs et de copier les bons entre guillemets. Copier, s'inspirer, on va dire, et plus particulièrement dans le contexte d'auditeurs ou de auditrice qui serait dans dans un cas similaire au mien, à savoir petite équipe. Pas plus que ça de personnes dédiées à chaque étape de la chaîne : les traductions, l’UX writing, l'accessibilité, le test, etc. Ajoutez dans votre veille tous ces sujets là. Moi, j'essaye de suivre des personnes autour de l’UX depuis des années, alors que j'ai une formation d'ingénieur et de coder, etc. Et je n'ai pas l'impression d'être expert là dedans. Mais j'ai l'impression, via ma veille, d'avoir gagné un peu en maturité par rapport à pas mal d'autres dev frontend. En plus, c'est hyper enrichissant. Et aussi il faut documenter. Je suis fan de documentation, documentée, vos décisions, tu en parlais un peu Hélène tout à l'heure, il y a un truc qui se fait dans tout ce qui est architecture et architecture logicielle, c'est les les ADR, les Architectures Decision Record, où en général, c'est un petit document dans lequel tu vas dire bon ben là, on avait besoin de faire des QR codes, on a essayé tel projet, tel projet, tel le projet et finalement, on a choisi QR Code JS 32, celui qui était à tel endroit sur GitHub parce que x parce que y et on n'a pas utilisé celui là parce que z, etc. Et je pense qu’au fur et à mesure, j'ai tendance à appliquer ça sur les domaines un peu moins techniques et plus liés au contenu et à ces choses là, de tracer les choses parce qu'en fait, historiquement, j'étais tout seul. Donc le bus factor, il y a énormément de choses qui sont encore dans ma tête et j'essaye le plus possible de les mettre par écrit, en fait. Voir de les automatiser si je peux. J'évoquais l'exemple avec les traductions, mais j'ai hâte de faire un truc où tu ne peux pas chiper des composants si tu as écrit GitHub avec un H minuscule ou des trucs dangereux.

- Cécile : Ce serait formidable. Merci beaucoup à tous les deux, pour ce temps qu'on a passé ensemble. Et puis à très bientôt